3.1 Field of the Invention
The exemplary, illustrative technology herein relates to wireless telecommunication. More particularly, the exemplary, illustrative technology herein relates to systems, software, and methods for monitoring and managing SMS messaging, and the effects of such monitoring and managing on various devices, with or without the knowledge or assistance of a device user. Methods of preventing or misleading device tracking attempts through SMS messaging are also described. The technology herein has applications in the areas of computer and electronic communications security, telecommunications, business methods for providing regulatory compliance, defense, law enforcement, and surveillance avoidance arts.
3.2 The Related Art
Wireless mobile devices are common today, and increasingly they are relied upon for both business and personal communication. As used herein, the phrase “wireless mobile devices” includes pagers, mobile phones, combination devices that include the functionality of mobile phones, pagers, and personal digital assistants (PDAs) or any other devices having similar capabilities to enable wireless communication of voice and/or data from a plurality of locations or while in transit between locations. These devices typically allow the exchange of textual information as well as voice and data, without the need for a physical connection (i.e., a wire or cable) between the devices, typically by use of electromagnetic transmissions (e.g. radio and/or light waves). Devices using wireless communications can be at a fixed location or be mobile. Fixed location wireless device allow wireless communication between a fixed location and a mobile device or between devices at two fixed locations. Mobile wireless devices permit communication between mobile devices; as well as between mobile wireless devices and fixed location devices. Mobile devices typically communicate using radio-frequency transmissions, though some can also communicate by way of modulated light waves, usually in the infrared frequency spectrum.
Wireless communication can be accomplished by short-range transmissions, where the distances are measured in inches or feet, such as wireless Local Area Networks (WLANs) (e.g. Wi-Fi, supported by the Wi-Fi Alliance) or wireless personal area networks (PANs, e.g., Bluetooth), or longer-range transmissions, where distances are measured in miles, such as cellular technologies (e.g., cdmaOne, defined by the International Telecommunications Union, an agency of the United Nations, which is often referred to as “CDMA”) or Global System for Mobile communications (GSM: originally from Groupe Special Mobile, of France). These capabilities result in a plurality of ways to access wireless mobile devices, from locations that are near the wireless mobile device as well as locations that could be anywhere in the world.
GSM is a commonly used mobile telephony standard that includes not only voice communication capability, but also specifies protocols for transmitting non-voice digital data. Short Message System (SMS) is one such protocol. SMS data is sent over the control channel used to communicate device presence to a cell tower or other cellular network access point, do call setup, assign frequencies for voice calls, and the like. SMS can be used to support services such as Wireless Application Protocol (WAP) alerts or access, and “text messaging” as well as Multimedia Messaging Service (MMS), which is a telecommunications standard for sending messages that include multimedia objects such as images, audio, video and Rich Text. These protocols can also be used to move data and software over-the-air (OTA) to and from mobile wireless devices for purposes such as installing software updates or communicating between users. The ability to exchange data wirelessly enables many useful functions of wireless mobile devices, and has helped make them almost ubiquitous for both business and personal uses. This capability also creates some problems, such as making it harder for organizations to monitor and control the movement of sensitive data, permitting installation of various forms of harmful software, such as viruses, covert monitoring applications, device trackers, identity theft software and software for authorizing purchases of goods or services without the device owner's knowledge or permission, and software that permits unauthorized data access. Means to detect, control and/or block these types of activities are needed, but current methods do not adequately accomplish this. In some cases only some communication paths are controlled (e.g. TCP/IP over WiFi), and in others only some protocols, or portions of protocols, are dealt with (e.g. SMS text messaging, but not other types of SMS messages).
In some cases the control or blocking of harmful activities is done in the network access provider's infrastructure, not in the mobile device; and if means are used to contact the device directly, without going through the network access provider, or if the device is taken to a location where a different network provider's service is used (“roaming”) that does not supply such protection to the device, the device, and its information and user, become vulnerable. The critical aspects of the means of detecting, controlling and/or blocking harmful activities need to be accomplished on the mobile device itself to eliminate these problems.
SMS, as used on current devices, was defined in the GSM series of standards in 1985 as a means of sending messages of up to 160 characters to and from GSM mobile devices. The popularity of SMS “text messaging” has led to SMS, or protocols substantially similar to SMS, being implemented on non-GSM networks and devices, often with gateway systems providing protocol translations between systems. Most SMS messages sent today by users are mobile-to-mobile “text messages”, though the standard supports other types of SMS messaging as well, such as WAP Push Service Load/Indication and SMS Class 2 SIM specific messages. Most users lack understanding of these other message types, and even when a device includes a capability to limit or disable them, users may not make use of this, or may use it incorrectly. This leaves the devices vulnerable to cyber attack. Other mobile devices may lack such limiting or disabling capabilities entirely, or provide them in ways that are insufficiently flexible and so discourage their use.
SMS messages comprise various information fields that specify their purpose, content, format, and handling. For example, the TP-PID field specifies the Protocol Identifier, which either refers to the higher layer protocol being used, or indicates interworking with a certain type of telematic device, and the TP-DCS field, which specifies the DataCodingScheme (defined in 3GPP TS 23.038) that can be used to specify the character type in use for the message, whether the message is classless or of class 0, 1, 2, or 3, message compression, etc. Used together, the TP-PID and TP-DCS fields determine the “message type” as used herein and described in Table 1.
TABLE 1Message TypesMessageTypeTP-PIDTP-DCSCommentText00000000 - Simple Text SMSxxxxxxxx - anyTP-DCS istypically0-generaldatacoding,uncompressed,noclass,defaultalphabet.001xxxxx - telematicxxxxxxxx - anyinterworkingApplication000xxxxx - SME-to-SMExxxxxxxx - anySM-ALprotocolprotocolID in bits4- 0 ofTP-PID.PID of 0used forMS to SCSMtransferData01111100 - ANSI-136 R-DATA1111xx10 orSM sent to00x1xx10 -(U)SIM.Class 2See GSMTS 11.14and 3GPPTS 31.10201111101 - ME Data download1111xx01 or00x1xx01 -Class 101111111 - SIM Data download1111xx10 orSM sent to00x1xx10 -(U)SIM.Class 2See GSMTS 51.011and 3GPPTS 31.102Message01000xxx - Replace SM Type 1-7xxxxxxxx - anyReplace01011111 - Return Call MessageDetect/Locate01000000 - SM Type 0xxxxxxxx - any“SilentSMS”Device01111110 - ME00010001 -see 3GPPSettingsDepersonalization SMUncompressed,TS 22.022DefaultAlphabet, andMessage Class 1(MEspecific)Unknown11xxxxxx - SC specific usexxxxxxxx - anyUse notdefined inthestandard
Message types not typically available to applications running on the wireless mobile device, such as Class 2 messages that are forwarded to the SIM for processing (e.g., ANSI-136 R-DATA and SIM Data download), or Type 0 “silent SMS” messages that can be deleted after they are acknowledged, are referred to herein as “infrastructure” messages. Some message types can be infrastructure messages or not, depending on the setting of the TP-DCS field, such as the Application message types, while others are defined by standards as being Class 2 messages and therefore infrastructure messages, such as the ANSI-136 R-DATA and SIM Data download variants of the data message type. Table 2 describes which message types can be infrastructure messages, and whether these should be mediated when being sent from a wireless mobile device (“MO”, for “Mobile Originated”) or sent to a wireless mobile device (“MT”, for “Mobile Terminated”), and what the concerns are for each (see Table 2).
TABLE 2Mediation and InfrastructurePossiblyMessageMediatedMediatedInfra-TypeMO?MT?structure?ConcernsTextYNNImproper informationsharing.ApplicationYYYInformation leaks,application abuse andexploitation.DataYYYSoftware and (U)SIMinteraction.MessageNNNNo serious concerns.ReplaceDetect/NNYWith radioLocateequipment, or SPcooperation, canlocate device to a cell.In some cases moreprecisely Change ofSP, denial of use,malware.DeviceNYYChange of SP, denialSettingsof use, malwareinstall, informationleaks, locationdetection, etc.UnknownYYYUnknown
A wireless mobile device can, in some exemplary devices such as cell phones, comprise a “handset” and a Subscriber Identity Module, or “SIM”. Typically a handset comprises user interface subsystems, one or more receivers and transmitters, at least one processor (CPU), and the wireless mobile device's operating system. The construction of wireless mobile devices such as telephony devices is well understood to those skilled in the art.
SIMs are usually one part of a removable smart card, and the combination of a SIM and the smart card is commonly referred to as a “SIM card”. In some exemplary GSM 3G devices these are referred to as a “USIM card”. Both SIM and USIM will be referred to herein as “SIM” when the context does not require specification of the 2G or 3G versions specifically. SIM cards securely store the service-subscriber key used to identify a subscriber to a given wireless network, and they also typically support a “SIM Application Toolkit” (STK), which is a standard of the GSM system that enables the SIM to initiate actions that can be used for various value added services, such as payment authorization for purchases. In GSM 2G networks, the STK is defined in the GSM 11.14 standard. In GSM 3G networks, the USIM Application Toolkit (USAT) is the equivalent of the STK, and is defined in standard 3GPP 31.111. (Both STK and USIM are referred to herein as “STK” when the context does not require specification of the 2G or 3G versions specifically.)
The STK comprises a set of functions programmed into the SIM card that define how the SIM can interact directly with the mobile device (commonly referred to in this context as a “handset”), and/or the network. The STK provides functions that can give commands to the handset, for example: to display a menu and ask for user input, to dial phone numbers, to send SMS, to communicate with handset via AT commands, to obtain Network Measurement Report (NMR) information regarding device location, or to control or access other device features. These functions enable the SIM to carry out an interactive exchange between a network application and the end user, and to provide or control access to the network. Details of STK capabilities and use are defined in the 3rd Generation Partnership Project (3GPP) Specification of the SIM Application Toolkit (STK) for the Subscriber Identity Module-Mobile Equipment (SIM-ME) interface (also known as the 11.14 specification) and related standards documents.
In addition to the STK, SIM cards can implement additional systems for supporting application programs that run on the SIM card. There are a plurality of systems and standards for such support, including the Open Platform and Java Card standards. Some standards support only one operating system or hardware smart card, others, like the Java Card standard, are supported on a plurality of smart cards under a plurality of operating systems. These systems can provide mechanisms for installing applications programs, selecting applications to execute, and means for the application programs to interact with each other or with the world outside of the smart card they are running on. Such systems typically provide for only one application to execute at a time, as is the case with the Java Card 2.2.1 standard, but others can provide for a plurality of applications to be active at the same time, or in a time-sliced multi-processing arrangement as is well known to those of skill in the art. These systems can provide mechanisms to isolate applications from each other, or provide only limited or controlled interaction between applications. For example, the Java Card 2.2.1 standard includes a “firewall” capability, sometimes referred to as a “sandbox”, that prevents applications from accessing each other's data or code objects, unless the applications are part of the same package or take special steps to permit such access. This “firewall” is between applications and does not include capability for filtering, blocking or otherwise monitoring or controlling the application's interaction with the world outside of the smart card, however, so the term “firewall” in this instance can be misleading. Due to the open-ended capabilities of applications installed on SIM cards there is a potential security hazard to SIM cards and to devices in which the cards are installed, similar to that of other general purpose computing devices. Given the use of SIM cards as means to authenticate users for purchase of goods and services over the network, such security hazards can involve identity theft and monetary losses. Therefore, methods for monitoring and controlling the communication activities of applications running on SIM cards in wireless mobile devices are needed to prevent such applications from being used to harm the wireless mobile device, the data held on or passing through such devices, for improper information disclosure, purchase authorization, or other abuses.
Although SIM cards originated with GSM devices, the cards have proven so useful that other network types have adopted similar mechanisms. For example, CDMA systems have implemented a SIM-like device called a Removable User Identity Module (R-UIM), and a more advanced version of this called a CDMA Subscriber Identity Module (CSIM), which are cards developed for CDMA handsets that are equivalent to a GSM SIM. The CSIM is physically compatible with GSM SIM cards, can fit into existing GSM phones, and is an extension of the GSM standard but is capable of working on both CDMA and GSM networks. As used hereinafter, “SIM card” refers to SIM, R-UIM, CSIM or similar devices where the capabilities are these are equivalent.
Most mobile wireless devices include a capability to be “provisioned”, that is to have their software updated and configuration values set, using the above-described OTA methods. In some cases, software can be installed even without notification to, or permission from, the user of the mobile device. Physical security of the device can protect against the installation of unwanted software using wired means, such as cables or by exchanging the SIM card, but due to the possibility of installing software OTA, physical security methods alone are not sufficient to protect a device. One common method of OTA provisioning involves the use of SMS messages that are interpreted by systems already installed on the device. In response to properly constructed SMS messages, a device can be induced to report its status, accept software updates, accept changes to device configuration, report the device's current location, and many other actions. Some such systems are incorporated into the SIM, the device OS or device hardware, while others are optionally installed by the network provider or device user.
It is not usually practical to block all OTA software installations and configuration changes, because many service providers use these methods to update the device's operating system, network access configuration, and other applications. Blocking all OTA software installations and configuration changes would interfere with normal device use and the functioning of the provider's system. Users may also want to acquire additional software OTA for legitimate purposes. Some means is needed to prevent, or at least detect, OTA installation of some software, while permitting OTA installation of other software on wireless mobile devices. Such means would enable the device user to be aware of OTA installation of software, and the user could then take appropriate action, such as approving the installation, rejecting the installation, or not using the device until improperly installed software can be removed. Similarly, it would be desirable to establish rules that control whether specific software or configuration changes can be made on a mobile device, and the circumstances under which they might be made.
Improper software installation is not the only hazard created by the use of wireless mobile devices. The potential for their use in improperly disclosing confidential information, whether intentionally or accidentally, is of great concern to government security agencies, the military, corporate entities, and others who deal with regulated, confidential, or classified information. Monitoring of an installation's phone and computer systems, and searching vehicles and packages at gates or exits is no longer sufficient to prevent classified or confidential information being sent to parties that should not have access to it. In some cases, there can be regulatory requirements to record certain information exchanges for future reference, such as is required by the Sarbanes-Oxley Act of 2002 (Public Law 107-204). Means to address such requirements exist for e-mail, telephone calls, traditional postal mail, and other forms of communication, but means to address SMS messages, or other similar protocols, such as MMS, are lacking. Attempting to monitor communications by means such as tracking e-mail messages at an e-mail server can be defeated by some device capabilities, such as the BLACKBERRY “PIN-to-PIN” message system, where e-mail messages are sent from a first wireless mobile device to a second wireless mobile device without using an e-mail server, or by configuring the mobile device to use a different e-mail server that does not perform tracking of messages. Some devices can make use of encryption to render messages opaque to monitoring attempts located on infrastructure components, such as SMSC or e-mail servers. Some means for monitoring and controlling information sent from or to a wireless mobile device, whether intentionally by the device user, or without the device user's knowledge or permission, and whether encrypted or not, and regardless of the path taken by the information, is required to restore the ability to monitor and control, or at least detect, information transmission between a wireless mobile device and other systems. There is a need for monitoring and control located in the wireless mobile device itself, because only systems located in the wireless mobile device have access to all information sent to or from the device in an accessible (not encrypted) form.
OTA message traffic can currently be monitored or captured using network hardware, such as the Short Message Service Center (SMSC), telephone switch, Internet-to-SMS gateway, or other server at a service provider. This requires explicit cooperation by the service provider and can require expensive monitoring equipment, making this method suitable for some government agencies, such as law enforcement, but not practical for use by corporate entities or other civilian organizations that do not have such access and may lack the required expertise or equipment. When using this technique, device control to prevent undesired use of the device, such as to improperly disclose information, is generally limited as well. Methods that operate on the device to detect, capture, store and relay SMS message traffic are needed.
In addition to the issues related to external message traffic, additional problems can be generated by message traffic between the SIM and the handset (sometimes referred to as “SIM pro-active commands”). Applications running in the SIM can cause the handset to make voice calls, send SMS messages, launch the handset's browser, display messages to the user, etc. Applications running in the handset can request that the SIM send messages, such as for purposes of making purchases, or to reveal the device's current location. Some means of monitoring and/or controlling such SIM/handset interaction is needed to limit potential harm to the device, device misuse, or improper information exchange.
FIG. 1 depicts the structure of an SMS Message as delivered to a wireless mobile device from an SMSC (SMS-DELIVER messages) which is familiar to those having ordinary skill in the art. The message contains a number of fields containing information useful to describe the message data, its routing, format, and other aspects. The Message Type Indicator (MTI) (1100) specifies the type of SMS message (i.e. deliver, submit, status report, etc.). More Messages To Send (MMS) (1110) tells the receiving device whether there are additional messages waiting. Reply Path (RP) (1120) specifies whether a Reply Path is set in the message. User Data Header Indicator (UDHI) (1130) specifies whether the User Data field contains only short message data, or whether the beginning of the User Data field contains a header in addition to the short message data. Status Report Indicator (SRI) (1140) specifies whether a status report should be returned for this SMS message. Originator Address (OA) (1150) specifies the address of the originator of the message. Protocol Identifier (PID) (1160) specifies information about the type and content of the message, such as whether the message is a Short Message (i.e. a “text message”), an SMS Type 0 message, a data download to the handset or to the SIM, etc. SMS Type 0 messages are used to query the device and are not stored, but can, on most provider networks, result in a receipt acknowledgment being sent to the requester, without notification to the receiving device user. On some provider networks, such “silent acks” are not permitted. Whether an acknowledgment of receipt (a “receipt ack”) is sent also depends on a bit being set in the request message, and in most cases this bit is not set, but this is an option for the sender of the message, and is not under control of the receiving device. By sending a message with the receipt ack bit set, a device can be made to re-register with the network to send the ack, and this can be used, with the proper equipment, to locate the device with respect to a particular cell. In some provider networks failure to send such acks can result in SMS messages being blocked until the message requesting the ack has been acknowledged, so simply blocking transmission of such acks is not practical. Data Coding Scheme (DCS) (1170) specifies additional information about the data format of the message, such as the character-encoding scheme as specified in the 3GPP TS 23.038 standard document. Service Center Time Stamp (SCTS) (1180) specifies the local time at which the message was sent. The User Data length (UDL) (1190) specifies the length of the User Data field. The User Data (UD) (1200) field contains the message data.
SMS messages sent from a wireless mobile device to an SMSC (SMS-SUBMIT messages) have a slightly different structure from those sent to wireless mobile devices as is known in art and shown in FIG. 2. Some fields, such as MTI (2100), RP (2130), UDHI (2150), PID (2180), DCS (2190), UDL (2210) and UD (2220) are similar to the same fields in SMS-DELIVER messages. Other fields include the following: Reject Duplicated (RD) (2110) specifies whether duplicate messages should be accepted or not; Validity Period Format (VPF) (2120) specifies whether the optional Validity Period (VP) (2200) field is present; Status Receipt Request (SRR) (2140) specifies whether a receipt report is wanted for this message; Message Reference (MR) (2160) specifies an incrementing integer that identifies this particular SMS-SUBMIT message; and Destination Address (DA) (2170) specifies the address of the intended recipient of the SMS message. Validity Period (VP) (2200) specifies how long the message can remain undelivered before the SMS message expires.
In both SMS-DELIVER and SMS-SUBMIT messages, the User Data (UD) field can contain either a Short Message, or a Header and a Short Message. The UDHI field specifies the presence of a Header in the UD. FIG. 3 depicts the format of a User Data (UD) field as known to those having ordinary skill in the art. The UD field contains a Header (3100-3190) in addition to a Short Message (3200). The Length of User Data Header field (3100) specifies the Header's length and is followed by one or more Info Element (IE) entries, each of which comprises three fields: an Info Element ID (3110, 3140 & 3170), an Info Element Length (3120, 3150, & 3180), and an Info Element Data field (3130, 3160, & 3190). The Info Element entries specify additional information or further describe the Short Message content. For example, an IE with an ID of ‘09’ (hexadecimal) specifies a Wireless Control Message (WAP). An IE with an ID of ‘20’ (hexadecimal) specifies an RFC 822 e-mail header. An IE with an ID of ‘70’ through ‘7F’ (hexadecimal) specifies a SIM Toolkit Security Header, as defined in 3GPP TSG 31.115. Info Element ID values essentially specify the “message type” of the SMS message.
The SMS message fields described above permit identification of the message type, its size, and its content; so that different types of SMS messages, those originating at various addresses, being sent to various addresses, or which specify particular operations, can be treated in different ways by the device OS as well as by exemplary embodiments of the current invention. Within the message structure described above, SMS messages exist in a variety of forms, and are used for a plurality of purposes. The most widely known form is called Simple Text SMS. Simple Text SMS messages are used by device users to send short text messages to other devices, and can be used by harmful software to exfiltrate (i.e. the opposite of “infiltrate” . . . to transfer out of a targeted device into one or more second devices) data or to receive control commands. SMS messages are limited to a few dozen bytes each, but by breaking messages into segments, sending each segment in a separate SMS message and reassembling the segments into the original message on the receiving device, larger messages can be transmitted. SMS Simple Text messages can easily be used to disclose confidential information. A method of monitoring, limiting, or blocking SMS Simple Text messages is required if prevention or detection of improper uses of SMS Simple Text capabilities is to be achieved, such as by blocking the sending of SMS Simple Text messages or recording them to detect and inhibit their use to disclose confidential information. Known methods for blocking SMS text messages typically exist as infrastructure applications running on network provider server equipment, not in the mobile device, and are usually intended to prevent sending of “spam” messages or to prevent Simple Text SMS messages from specific senders. SMS text message blocking on the wireless device is known, and generally involves use of “allow lists” (numbers permitted to send SMS text messages), or “deny lists” (numbers not permitted to send SMS text messages). Such applications can often be subverted or bypassed, such as by using a device that is not on a deny list or that is listed on an allow list, and there is nothing to prevent the device user from disabling or removing the blocking application, making such programs unsuitable for involuntary use (e.g. for corporate or government security monitoring and preservation). Other known applications can suppress SMS text messages based on message content, but such applications operate at the application programming interface (API) level, and access already-delivered messages from the “inbox” (i.e. the received message storage area). While this may be sufficient to prevent a user from seeing unwanted messages, there is usually no way to prevent other applications from having access to the received SMS message, or to know if one or more of them have processed the message content prior to suppression of the message. Dealing with messages after they have been received and processed into the device inbox is insufficient for preventing harm from hostile SMS messages. Unrestricted and unmonitored Simple Text SMS messages pose a risk for sensitive information dissemination, and can contribute to compromising the security of a device by providing a control and update pathway for covertly installed software. A means of blocking, filtering, modifying and/or recording Simple Text SMS messages is needed, and for some purposes this means should be resistant to disabling or removal by the device user, or may need to be covertly implemented so that the user is unaware that the blocking, filtering, modifying and/or recording of Simple Text SMS messages is occurring.
If a device has been compromised by the installation of covert monitoring or control software, the collected monitoring results, or other desired information present on the device, must be sent without detection by the device user (covertly exfiltrated). One method of covertly exfiltrating collected monitoring results is by way of SMS messages. An ability to detect, monitor, block, or limit SMS messages being sent from a device can remove this exfiltration pathway from the available methods that can be used by such software, and improve the security of wireless mobile devices and the data that passes through them. Current methods for preventing SMS use for covertly exfiltrating data lack flexibility and can be subverted or bypassed. Methods are needed which are flexible and which at least detect SMS messages in those cases where they can't monitor and/or control them.
Still other risks from unrestricted SMS use exist. For instance, SMS messages can be used to trigger applications installed on a device into responding to the SMS message. This response can include location information concerning the cell or cells that the device is currently located in. Such location information can be useful for locating the device user for purposes of tracking, kidnapping, or harming the device user. When devices include GPS receivers, SIM card interactions can result in the GPS-derived location information being sent to unauthorized recipients, making the current location of the device, and therefore its user, known to a very precise degree. In some situations the device location can be determined to within a 30-foot radius. Some means of limiting or preventing such location information being disclosed inappropriately are needed, while not interfering with desirable sharing of location information or use of GPS receiver hardware for navigation or other purposes, such as location of nearby businesses or services.
Two other commonly used SMS message types are WAP Push Service Load (SL) and WAP Push Service Indication (SI) messages. SI messages are used to notify the device user that new WAP content is available. SL messages cause the device's browser to load the referenced content, optionally without user intervention on some devices. Other devices, such as those running the Symbian OS, require user interaction. SL message actions can be limited based on the security level settings of the device in some cases. Unrestricted and unmonitored WAP Push messages can pose a serious risk to the security of a wireless device when combined with an unaware user who follows a pushed link to a hostile web service, or with browser flaws that permit hostile web services to exploit the wireless device without user interaction or awareness. Some means of monitoring, limiting, or at least detecting SL and SI messages is required.
Another form of SMS message is the SIM Application Toolkit (STK) message. STK messages allows access to the SIM to use or alter the services supported by the device, and to download new services using OTA methods. For example, network operators can remotely provision a wireless device by sending text and/or binary commands and/or binary data embedded in SMS messages. Unlike a typical device application program, the STK executes on the SIM card, not in the device processor(s). STK messages on some devices are not processed at all by the handset, other than to recognize that they are STK messages, and such messages are passed into the SIM card and processed there. Applications that deal with SMS messages on the handset through OS-provided APIs may not have access to STK messages as they typically are not placed into the SMS “inbox” by the wireless device. Such applications are blind to STK messages, and can not block, control, log or do anything else to detect or prevent harm from them. Since the STK comprises functions that can cause the handset to perform potentially harmful actions, such as sending confidential or classified data in SMS Simple Text messages or establishing voice communication between the handset and a remote device, some means of detecting, monitoring, limiting or blocking STK messages is needed.
Within the STK specification, SMS is a key mechanism for personalizing the SIM in each device. The STK has been fully ratified as part of the GSM standard and is incorporated into several manufacturers' devices, both those intended for use on GSM phone networks, and others. The STK has been incorporated into several commercial and trial network services, from mobile banking to information services and email. Given the sensitivity of the information involved, and the potential for altering the device's basic settings, without user awareness in some cases, unrestricted and unmonitored STK messages are a risk to the security of wireless devices that support them, and to the data integrity and confidentiality of the information stored or passing through them. Some means of monitoring, limiting, or at least detecting such messages is required. This requirement exists whether the SMS messages are received over the GSM command channel, an equivalent SMS mechanism in a non-GSM system, such as CDMA, or a different type of communication channel, such as TCP/IP over WiFi or another transport, such as Bluetooth, or by other means, such as IRdA, USB, or Ethernet.
Some network providers (e.g. Verizon Wireless, T-Mobile and AT&T) include filtering of SMS messages as part of their service or security infrastructure. In some cases this filtering involves suppression of “spam” text messages, and/or allow/deny listing for a particular device of particular sender numbers specified by a user of the device. In some cases the SMS filtering goes farther, and suppresses relaying of messages having types that are potentially harmful, such as messages that can be used to change the provisioning of a device, messages that can be used to find the location of a device, and messages that invoke STK functions. Such filtering and suppression of harmful messages is worthwhile, but since it is done in the provider's infrastructure servers, such as an SMSC, there is no protection offered for devices that receive SMS messages by other pathways. For instance, a transmitter in the vicinity of a wireless device could broadcast a signal that overrides that of a local cell tower, and masquerades as that cell tower. The wireless device, not being able to tell the difference between the actual cell tower and the transmitter acting as the local cell tower, will accept SMS messages as coming from the provider's systems, and process them normally. If the masquerading transmitter sends SMS messages that alter provisioning, install software, access files, or other improper actions, these will succeed when the wireless device is relying on the provider's systems to provide security. In a more common scenario, when the mobile device user leaves his home area and is “roaming”, the mobile device will be connecting to a different provider network, which may or may not provide SMS filtering or blocking similar to that of the user's own network provider. The mobile device thus becomes vulnerable when it roams to any provider network that doesn't provide SMS filtering and blocking services. A method for the wireless device to provide its own filtering and blocking functions for improper messages is needed.
Some wireless device OSs provide mechanisms to permit the an application to easily become part of the SMS message processing flow, while others do not. For example, the Microsoft Mobile OS provides an Application Programming Interface (API) that permits capture of certain types of SMS message. One problem with relying on such mechanisms for intercepting SMS message traffic is that other applications can also make use of them, and can interfere with the proper operation of the intercepting application, such as by gaining access to SMS messages prior to their being processed by the intercepting application. In addition, such APIs do not typically permit the required operations to be carried out on all SMS message types, or do not ensure that the SMS messages will not have effects on the device even if they are available through the API. APIs can also limit what effects an application can have on an SMS message, such as not supporting modification of SMS messages prior to any other process gaining access to them. For these and other reasons, an intercepting application can not rely on such APIs, and must use other means to ensure interception of all SMS messages prior to their resulting in unwanted effects on the device or the information it contains.
There are some on-device SMS filtering systems in the prior art, such as MCleaner (Beijing Mobile Security Technology Co. Ltd, China), and Kaspersky Anti-Virus Mobile Enterprise Edition (Kaspersky Lab, Woburn, Mass.), but these have some limitations that keep them from providing all of the security capabilities needed to address the risks described herein. For example, a well known limitation is that these applications do not intercept all SMS message types because they access messages using the “inbox”, typically through an OS-provided API. They typically provide allow/deny filtering by sender number, but little else. Some include filtering by matching text against the message content. Most only filter incoming messages, and do not limit what is sent from the mobile device (outgoing messages), rendering them useless for purposes of monitoring SMS communication for policy, legal or regulatory compliance purposes. By limiting filtering and blocking to short text messages, they leave the mobile device open to messages that change configuration settings or installed software. In addition, existing SMS on-device “firewalls” typically intercept messages after they are placed in the “in box” on the mobile device, and can not guarantee that the message has not already been processed by other on-device software, such as the OS, other user level applications, or the STK, thus the message might already have had an effect on the device before these prior art systems take any actions. A message might even have been processed and deleted without being seen by these programs. To be truly effective in protecting the mobile device from unwanted SMS messages, or for monitoring and/or limiting SMS message use for exchange of information, SMS messages must be intercepted as early in the process of receiving them on the mobile device as possible, within the constraints created by the mobile device hardware and OS designs.
Thus a need exists to provide methods, software, systems, and devices that better protect SMS messaging, particularly those messages that cause a mobile device's configuration to be changed without a user's knowledge or permission, and this protection needs to be provided in the mobile device, not just on provider infrastructure systems. Additionally, there is a need for preventing the use of wireless mobile device SMS capabilities for unwanted purposes, such as disclosing confidential information, or the installation of software for covert monitoring or control of a mobile device's operation or improper disclosure of the device location, while allowing the device to remain normally functional. The exemplary illustrative technology herein addresses these and other important needs.